As always, will Flashbots find the way?

1. The Next Challenge for Ethereum: Builder Centralization

Ethereum is often regarded as one of the most decentralized networks alongside Bitcoin. Due to the relatively low hardware requirements for operating an Ethereum node, almost anyone can run a node. There’s some redundancy though, the network boasts over 1 million validators.

However, a critical issue often overlooked is builder centralization. Builders are the entities that gather transactions and bundles to create blocks on the Ethereum network. Over the past seven days, 95% of blocks were generated by just three builders.

Despite this, as Vitalik Buterin has pointed out, builder centralization does not pose a severe threat to the overall security of the Ethereum network. This is because, even if block building is somewhat centralized, the validators(proposers) who verify these blocks remain decentralized. Nonetheless, builder centralization can lead to various problems such as censorship, rent-seeking, and liveness issues.

This article will explore the journey of Flashbots in addressing the negative externalities of Ethereum's MEV and examine how SUAVE could ultimately resolve issues related to MEV, including builder centralization.

2. Progress So Far

2.1 Proof of Work

Before The Merge upgrade, the Ethereum network operated on PoW consensus, similar to the Bitcoin network, where miners used hardware to mine blocks. During this period, when searchers identified MEV opportunities in the mempool, the only way to get their transactions or bundles included in a block was through a priority gas auction (PGA), where they bid higher gas fees than other searchers.

There were fundamental problems with this approach. First, MEV stealing was an issue. Miners could see the contents of the transactions or bundles submitted by searchers and, instead of including them in the block for a priority fee, they could copy these transactions and steal the MEV themselves. Thus, searchers had to trust miners to earn MEV profits.

The second problem was network congestion. Whenever MEV opportunities arose, searchers competed by bidding higher priority fees, which led to increased congestion on the Ethereum network. This made average transaction fees expensive and unpredictable, negatively impacting regular users.

To address the negative externalities of MEV on the PoW Ethereum network, Flashbots introduced the Flashbots Auction, consisting of mev-geth and mev-relay. The key components were: 1) whitelisting miners, 2) establishing a private mempool, and 3) implementing a sealed bid auction system.

Users and searchers could submit transactions or bundles to the private mempool of Flashbots Auction, which were then sent to whitelisted miners using the mev-geth client via a centralized mev-relay. Searchers expressed bids for their bundles, and miners used mev-geth to include the highest bidding bundles in the block.

Unlike the previous system, searchers used a private mempool, so their actions didn't impact the Ethereum gas market, and they couldn't see other searchers' bids, reducing competition. Consequently, Flashbots Auction effectively reduced congestion on the Ethereum network. However, whitelisting miners was still necessary because they could still see the content of bundles submitted by searchers.

Flashbots Auction became widely adopted, with over 90% adoption of mev-geth. This significantly reduced failed MEV transactions and lowered average gas fees on the Ethereum network, effectively mitigating many of the negative externalities associated with MEV.

2.2 Proof of Stake (PoS)

In September 2022, the Ethereum network transitioned from PoW to PoS with the activation of The Merge upgrade. The process of including user-submitted transactions in blocks remained largely unchanged from PoW. However, there was a critical issue with adopting Flashbots Auction directly: whitelisting.

In PoW Ethereum, miners physically owned their hardware, making the whitelisting process relatively straightforward. However, with the switch to PoS, a wide range of entities could participate in validating anonymously, making whitelisting extremely difficult.

To address the negative externalities of MEV on PoS Ethereum, Flashbots introduced a new protocol called MEV-Boost. The Ethereum network roadmap includes the PBS (Proposer-Builder Separation) upgrade to decentralize MEV, and MEV-Boost implements part of PBS.

In this new setup, block builders receive transactions and bundles from users and searchers to create the most valuable full block, while proposers select the highest bid full block from block builders and propagate it to the network. Unlike mev-geth, MEV-Boost acts as a sidecar to the consensus client, making it compatible with any client type.

Here’s how MEV-Boost operates:

1. Block builders receive transactions from searchers and private order flow, using their MEV extraction algorithms to reorder transactions for maximum profitability. They then create a full block and submit a bid to the relay.

2. The relay verifies the validity of blocks received from builders and stores them.

3. The relay sends the block headers, along with bids, to the proposer.

4. The proposer selects the block header with the highest bid from those sent by the relay and signs it.

5. The relay reveals the full block content corresponding to the signed header to the proposer.

6. The proposer submits the complete block to the network and collects the bid attached by the block builder.

From the perspective of Ethereum validators, MEV-Boost offers a significant advantage: there is no need for a whitelisting process. Validators simply run Flashbots' MEV-Boost, and block builders just extract the highest value MEV and submit it as bids. This means validators can earn MEV revenue without needing their own MEV extraction algorithms. Consequently, MEV profits are decentralized rather than being concentrated among a few entities.

Despite being an external middleware rather than a built-in protocol, MEV-Boost has been successfully adopted by over 90% of Ethereum validators for an extended period. While there is a drawback that builders and proposers must trust the relay, the number of relays has increased to eight, reducing Flashbots relay's dominance and alleviating related concerns such as censorship.

3. Builder Centralization

3.1 Why Builders Tend Toward Centralization

While MEV-Boost has mitigated many of the negative externalities associated with MEV, the issue of builder centralization, mentioned earlier, remains unresolved. Currently, around 90% of Ethereum network blocks are created by just three to four block builders. But why do block builders tend to centralize? There are two main reasons:

Exclusive Order Flow (EOF)

Firstly, the block builder market is fundamentally a winner-takes-all market. Imagine you are a searcher who has identified an MEV extraction opportunity and bundled it. Which builders will you send your bundle to? While you could send it to all builders, the more builders you involve, the higher the risk of MEV stealing, as builders can see the content of the bundle. Therefore, your optimal strategy would be to send the bundle only to the top few builders with the highest probability of block inclusion.

The graph above shows that builders receiving more bundles from searchers have a higher probability of block inclusion. This phenomenon accelerates the centralization flywheel: if a builder receives more bundles from searchers, it is more likely to build more profitable blocks. Consequently, these blocks are more likely to be adopted by proposers on the Ethereum network, incentivizing more searchers to send their bundles to that builder. Sending bundles to less dominant builders could result in delays in block inclusion, making gas fee predictions difficult and potentially losing MEV extraction opportunities.

Beyond this natural tendency towards centralization, builders can source additional transactions or bundles through EOF. For example, a specific builder might offer privacy guarantees or a share of the extracted MEV to users and searchers who send transactions or bundles exclusively to them. This additional order flow, inaccessible to other builders, further accelerates builder centralization.

Indeed, as shown in the graph, BloXroute has a significantly higher block inclusion rate compared to its peers. This is because BloXroute operates not only as a block builder but also as a relay service, giving it a latency advantage in processing transactions. Additionally, BloXroute sources EOF through services like BackRunMe.

BackRunMe allows users to submit private transactions, protecting them from malicious attacks like front-running and sandwich attacks. Moreover, if MEV profits are generated from backrunning the private transactions submitted to BackRunMe, the profits are distributed according to the ratios shown in the chart. Users and searchers can enjoy various benefits by using BackRunMe's swap UI or simply changing their RPC to submit transactions.

So, what can new block builders do? Unfortunately, they have limited options other than increasing their market share at a loss or offering services to attract users and searchers' EOF. The former approach, known as a block subsidization strategy, involves setting higher bids than the MEV profits generated from building blocks to increase the block inclusion rate. For example, the f1b builder successfully used this strategy to quickly increase their searcher count.

Cross-Domain MEV

The more order flow a block builder has access to, the higher the probability of generating more profitable blocks. If some block builders also create blocks for other networks, they can access not only the order flow from the Ethereum network but also external order flow. This capability would likely lead to further centralization around these builders.

3.2 What Should We Do?

We've explored why the builder market tends to centralize. Although centralization of builders does not pose a severe security threat due to the decentralized nature of proposers (validators) who verify and propagate blocks, it can still lead to issues such as 1) censorship, 2) rent-seeking, and 3) liveness problems.

Censorship could potentially be addressed by future Ethereum protocol features like crList, which would natively force builders to include all transactions as required by proposers. However, addressing rent-seeking in a monopolistic market and resolving liveness issues due to downtime is more challenging.

Therefore, the best solution is to prevent builder centralization in the first place by mitigating its main causes—EOF and cross-domain MEV. To address these issues, Flashbots introduced the Single Unifying Auction for Value Expression (SUAVE) protocol. (It's worth noting that SUAVE is not the only potential solution to builder centralization; for a variety of other potential solutions, see Jon Charbonneau’s 'Decentralizing the Builder Role').

4. Here Comes SUAVE

4.1 TL;DR

SUAVE focuses on addressing the two main factors contributing to builder centralization: EOF and cross-domain MEV. Firstly, SUAVE can accept transactions from all networks, enabling decentralized builders to inherently extract cross-domain MEV. Secondly, SUAVE optimizes conditions for users by privately handling preferences and offering a share of MEV profits.

4.2 Overview

SUAVE is a separate blockchain from the Ethereum network, offering a plug-and-play mempool and decentralized builder service that can be used by multiple networks. This allows other networks to outsource the complex processes of mempool management and decentralized block building to SUAVE. SUAVE consists of three main components:

Universal Preference Environment

Users and searchers submit transactions, bundles, intents, and other expressions of preferences to SUAVE's mempool, instead of the original network's mempool, along with their bids. In SUAVE, these preferences are treated as a native transaction type. By aggregating preferences from various domains into a single mempool, the probability of optimal execution increases. This setup benefits builders by lowering entry barriers and increasing potential profits.

Optimal Execution Market

Executors (Searchers, Builders, etc.) monitor the SUAVE mempool and compete to create bundles with the best execution conditions. A key concept introduced here is the order flow auction (OFA).

In the traditional MEV-Boost model, MEV profits flow in a single direction from users to searchers to builders to proposers. However, with OFA, executors compete for users' preferences, allowing users to also receive a share of the MEV profits. This strategy is similar to services like BackRunMe, which aim to attract more EOF by redistributing some MEV profits to users and searchers. Additionally, SUAVE ensures the privacy of preferences in its mempool, protecting them from malicious MEV attacks.

The difference is that, while such strategies can lead to the centralization of specific builders in the current builder market, SUAVE embeds OFA into the protocol itself, giving all decentralized builders access to these preferences. The concept of OFA, as proposed by Flashbots, is already implemented in the Ethereum network through MEV-Share and will later be incorporated into SUAVE.

Decentralized Block Building

In the previous components, most preferences find their optimal execution route. Decentralized block builders then use this information to construct partial or full blocks that maximize MEV profits, which they then pass on to validators of various networks.

Not all validators of other networks may use SUAVE, similar to how not all Ethereum validators use MEV-Boost. Validators listening to SUAVE can accept SUAVE blocks and add profitable blocks to their network. If they are SUAVE-unaware, SUAVE's block builders must participate in a priority gas auction (PGA) to get their blocks included. Once preferences are fulfilled in the destination chain, an oracle notifies the SUAVE network, and the bid is sent to executors for settlement.

4.3 MEVM

SUAVE is a blockchain that uses MEVM as its execution environment. The MEVM is built on the EVM framework, with added precompiles for MEV use cases. Developers can use Solidity to create MEV applications as smart contracts, enabling the decentralized building of previously centralized MEV-related infrastructure. For example, different methods of block building or order flow auctions can be implemented as smart contracts.

Given the need for sensitive data and computations, MEVM also offers privacy features. Sensitive computations are executed off-chain by execution nodes. Initially, Flashbots or third parties will provide this in centralized way but eventually, it will be executed in trusted execution environments (TEE) like Intel SGX.

5. Summary & Challenges Ahead

In summary, SUAVE aims to collect transactions from all blockchain networks and provide blocks with the most efficient execution to those networks. If SUAVE's vision is fully realized, it will enable true decentralization of MEV, offering the following benefits to various participants in the blockchain ecosystem:

• Users: Protected from malicious MEV attacks through privacy and offered the best execution.

• Builders: Can compete fairly with other builders due to SUAVE’s inherent privacy transactions and order flow auctions (OFA), and have access to cross-domain preferences, enabling them to build more profitable blocks than when operating within a single domain.

• Networks: Can easily outsource the block-building process to SUAVE.

Despite its ambitious vision, SUAVE is still in its early stages and faces several challenges before it can be fully realized.

• Security Model: SUAVE’s security model is still undefined. Given that SUAVE blocks are likely to be used in Ethereum and Ethereum-based L2 networks, its security level ideally should match that of Ethereum, but achieving this is complex. There are discussions on whether SUAVE should be built as an Ethereum L2 or use EigenLayer’s crypto-economic security.

• Atomic Cross-Domain Transactions: These are not guaranteed. It is challenging to process transactions atomically across networks with different block times. A transaction might succeed on a fast-block-time network but fail on a slower one. Additionally, since not all validators on all networks are SUAVE-aware, including blocks via a priority gas auction (PGA) might fail.

• Oracle Design: A sophisticated oracle design is needed to accurately and swiftly bring results from external domains into SUAVE for settlement. Oracles must be at least as secure as SUAVE, as they can become attack vectors.

• User Experience: A user-friendly UX must be designed for SUAVE. Users need to set bids for their preferences and hold ETH in the SUAVE network. An interface that allows users to easily express various types of preferences is also necessary.

The biggest concern is whether SUAVE can achieve a significant adoption rate similar to mev-geth or MEV-Boost. For SUAVE to realize its vision, it must achieve economies of scale. Many users from numerous networks need to send their preferences to SUAVE, and numerous builders must participate to create an efficient system. While mev-geth was a client and MEV-Boost was a middleware sidecar that existing validators could easily adopt, SUAVE is a blockchain network based on MEVM. Therefore, it remains to be seen whether this large system can achieve meaningful adoption across many networks.